I like this idea. How about taking it one step higher to MigrationLoaderFactory so that it's no longer file based? Basically, you can abstract the Migration and get an iterator of them.

Yea I agree, we have a MigrationLoader so a MigrationLoader factory makes a lot of sense. The FileMigrationLoader is just an implementation.
It might be more useful to just give it the path(),environment() for flexibility.

Thank you guys for the quick feedback!

How about taking it one step higher to MigrationLoaderFactory so that it's no longer file based?

I thought about that.
The return type of FileMigrationLoaderFactory#create() is MigrationLoader, so by design, it is possible to return a custom MigrationLoader that loads migrations from some other source (i.e. it does not have to be a subclass of FileMigrationLoader).

But this is BaseCommand which is the base class for the command line API and the current command line workflow cannot be separated from files completely (e.g. migrate new).
That is why I named it FileMigrationLoaderFactory.

It might be more useful to just give it the path(),environment() for flexibility.

It was my first implementation and I'm still not that sure which is better, so if you think that is better, I'll change. :)

Yea it's tied to Files atm but we also have for example JavaMigrationLoader that is useful for runtime migrations.

I saw that. But

JavaMigrationLoader has a method getMigrations() which returns a List<Change> (counter conventional, btw).

When you look at Change you see

public class Change implements Comparable<Change>, Cloneable {

  private BigDecimal id;
  private String description;
  private String appliedTimestamp;
  private String filename;
}

Notice the part where it says fileName? It's still anchored to the file system.

Side question: Why is the id BigDecimal? Do you expect a version like 3.1415926?

Not sure what you mean @chb0github, both have getMigrations which returns a list of changes.

Even if we change the signature of create() method as @h3adache suggested, it still is coupled with file system and FileMigrationLoaderFactory describes the purpose of this class more accurately, IMO.

That is true. I was just thinking about it from a Factory standpoint. The factory author can create the loader any way they like so I just assumed they would have the proper classLoader/packageNames to create the JavaMigrationLoader

@harawata if you have no more changes let's pull this in. Don't worry about the Factory idea for now. We can deal with it when we have to like you said

@h3adache ,
Okay!
Regarding the arguments of create(), I re-checked SelectedPaths and Environment and couldn't think of a good use case for other properties.
Let's merge this as it is and see what users say.

I'll add documentation and tests as soon as possible.

Thank you both for insightful comments!

I use it to create a JarFileMigrationLoader. :)
ATM our FileMigrationLoader doesn't read jar bundled migrations properly.
I create a JarFileMigrationLoader to handle that for me but I read the properties from the bundled environment file in the jar as well.

@h3adache Done! b95e393